正論は「デバッグ」には効くが、「デプロイ」には不十分だ：マネジメントにおけるモメンタムの力

ソフトウェアエンジニアという生き物は、職業柄「問題を解くこと」に特化しています。バグがあれば原因を突き止め、非効率なコードがあればリファクタリングする。この「正論で攻める」というアプローチは、コードを綺麗にする上では正解です。議論を深め、チームをより良くするという観点でも、論理的な正しさは不可欠ですよね。

しかし、実際の現場で正論だけで突き進もうとすると、まるで計算資源を使い果たしたサーバーのように、メンバーが疲弊してレスポンスを返さなくなることがあります。そこで重要になるのが「モメンタム（勢い）」の醸成なんです。

正論という名の「デッドロック」

何か問題が起きたとき、エンジニアはつい「正論」という名の強力なリミッターをかけがちです。

例えば、誰かが投げた改善案に対して「それは根本的な解決になっていない」「負債を増やすだけだ」と正論をぶつける。指摘自体は正しいのですが、これが重なるとチームの活動が「デッドロック」状態に陥ります。誰もが「どうせ正論で叩かれるなら、何もしないほうがマシだ」と考え始めてしまうわけです。

マネジメントにおいては、この「正しさによる停滞」を回避し、チームが前進しているという感覚、つまりモメンタムを維持することが最優先事項になります。

「問題への群がり」を肯定する

チームで何かトラブルが発生したとき、特定の詳しい人だけでなく、関係のないメンバーまでもが「わっ」と群がることがありますよね。

効率性の観点から見れば、これは「リソースの無駄遣い」です。わかっている人が一人でサクッと直せば、他のメンバーは自分のタスクを進められる。並列処理としては、そちらのほうがスループットは高いはずです。

ですが、これを否定してはいけません。全員で一つの問題に立ち向かっている姿は、チームの一体感を生む「同期処理」のようなものです。これは、みんながシステムの中身を知るための絶好のオンボーディング機会でもあります。一丸となっている姿をまずは肯定すべきなんです。

もちろん、長期的な面で見れば、いつまでも全員で一つのバグを追い続けるのは非効率です。モメンタムが十分に高まった段階で、「次はどうすれば、この熱量を維持したまま役割分担を最適化できるか」という話を切り出すのが、マネージャーの腕の見せ所というわけです。

障害対応における「沈黙」と「称賛」

一番「正論」が出やすいのが、ユーザーに影響が出ている障害対応の現場です。

エンジニアを長く続けていると、目の前の暫定対応に対して「なぜそもそもこんな設計にしたのか」「根本的な解決になっていないじゃないか」と突っ込みたくなることが多々あります。いわば、技術的負債に対する「コードレビュー」をその場で始めたくなる衝動です。

そこは、ぐっとこらえる必要があります。

火が吹いている最中に設計の是非を説くのは、本番環境でマイグレーションを回し始めるくらい危険な行為です。まずは、時間軸を優先して対応したこと自体を「素晴らしい」とストレートに伝えるべきです。迅速なパッチ当ては、サービスを救う正義ですから。

その上で、モメンタムを殺さないように別の場を設けます。「今回の対応は完璧だった。次は、これを二度と起こさないための根本治療を考えたいんだけど、いつ時間を取ろうか？」と、次のフェーズへの接続を提案する。

正論を「今すぐ実行するコマンド」として叩き込むのではなく、チームの「バックログ」に正しく積む。これが、エンジニアのプライドを守りつつ、チームの勢いを止めないためのマネジメント・パターンなんです。

結論

エンジニアリングの世界において、論理的な正しさは絶対的な価値を持ちます。しかし、人間が集まった「チーム」というシステムは、論理だけで駆動するわけではありません。

正論で誰かを追い詰めることは、短期的には問題を解決したように見えても、長期的にはチームの「開発速度（ベロシティ）」を著しく低下させます。マネジメントの本質は、正論を武器にするのではなく、チームが「勝っている」という感覚を維持するための、モメンタムの制御にあると言えるでしょう。